This invention relates generally to methods and systems for retrieving information descriptive of graphic elements that are displayed to a user interface and, more particularly, relates to methods and systems for retrieving graphics primitives and associated attributes of such graphics primitives of a display object rendered to a user interface.
To successfully compete in the global market, a company""s advertising literature and products must be easily understood by everyone, regardless of language or cultural differences. This requirement is perhaps most apparent within the vast software technology market, where software tools such as Microsoft Word, are commonplace on a global scale and must be comprehensible to users of any culture. The need for the accurate representation of language within software products marketed and sold worldwide is the essence of the localization industry. Localization of a product is the accurate translation and adaptation of any software or executable/viewable code into the language of the locality into which the product is being marketed and sold.
In order to work effectively across geographic and cultural borders, a localized software product must have the highest quality translation from a source language to a native or local language while retaining the functionality of the original product. The layout of text within a graphical user interface (GUI) is one of the biggest obstacles to overcome when localizing a product because the localized version of code must have the same general appearance and meaning as the original. This requires that the localization tool used to perform the translation be able to completely access and receive as input all of the graphics primitives that are rendered to the user interface screen during the execution of the software application. A graphics primitive is a drawing element, such as a text character, line, arc, polygon, etc., that is drawn to a user interface according to the specific function calls and mechanisms of the operating system. Each graphics primitive has its own set of attributes that define its appearance and/or style within the user interface. These attributes include visual and stylistic characteristics such as the text style or font, line length and style, arc length, etc. In GUI based software applications, multiple graphics primitives are combined to create the various display objects (e.g. buttons, menus, dialogue boxes, etc.) that are displayed to the user when they are using the application.
Because a typical application can include many different display objects, the graphics primitives that comprise the objects provide the primary information and data to be localized. For instance, a display object such as a dialog box can include a data entry field, user buttons containing text characters or strings, and/or other graphics primitives. To properly translate the text strings, the localization tool must be able to access all of the text primitives for the dialog box. Likewise, the specific attributes of the button, such as the length and shape of the button, must be known in order to account for changes in the length of a string due to translation. Once the graphics primitives that comprise the various display objects are determined, they can be localized accordingly, and the user interface of the application as a whole can be modified to suit the intended locality.
The graphics primitives that comprise the various display objects within an application can be accessed by conventional means. In Windows based applications for example, the graphics primitives are indicated by a resource file (*.res) that is stored within the application""s executable (*.exe). Resource files are simply plain text scripts that indicate the various resources required for the application to run successfully, and can be viewed with a standard resource editor/viewer tool. The resource files are converted into a binary representation at compile time, and then merged into the executable image of the application during runtime. Resource types include text string tables, which contain the various text strings that are displayed by the application during runtime. Other resource types often required by an application include menus, dialog boxes, cursors, icons, toolbars, bitmaps and other display objects composed of one or more graphics primitives. The resource files provide access to all of the display objects, and consequently the graphics primitives associated with the application.
Despite the extensive information provided from the resource files, however, many localization errors still occur because one or more text strings are missed during the localization process. This is because standard methods of capturing graphics primitives and associated attributes of such graphics primitives are limited to only those display objects that are standard objects of the operating system (OS). Yet, there are many GUI based software applications that contain xe2x80x9ccustom-classxe2x80x9d or xe2x80x9cowner-drawxe2x80x9d controls. These types of controls represent customized display objects that perform special functions or that have attributes that differ from the standard set of objects provided by the OS. So, while these customized objects are indicated as resources of the application within the resource file, the specific graphics primitives and associated attributes of the primitives that comprise the objects cannot be obtained directly from the resource file for localization. Rather, the primitives of customized display objects cannot be revealed until the object is invoked by the application during runtime.
Access to the graphics primitives that comprise the various display objects within the application, however, is still not enough to ensure a literal translation of a software product. The localization tool must also be able to know where and how the various text strings indicated in the resource file are used within the application. As described, the resource file indicates all of the graphics primitives relative to the executable application, and includes a text string table that contains the various literal strings and text characters displayed by the application during runtime. While the strings within the table can be easily accessed and localized accordingly, the table does not explicitly indicate the display object that a particular string corresponds to. The actual usage, or context of the string cannot be determined until it is displayed by the application during runtime. Context refers specifically to any information that allows the localization tool to account for the differences in meaning that occur when the same string or phrase is displayed in different ways within the application. For example, the term xe2x80x98O.K.xe2x80x99 may have a different meaning as it appears in a dialogue box than in a pull-down menu.
In addition to having accurately translated strings that are used in the correct context, the localized product must also maintain the same font properties as the original application. For instance, a button within the original application having text that reads xe2x80x9cEXITxe2x80x9d should read as xe2x80x9cSALIDAxe2x80x9d when localized for Spanish speaking users. The literal meaning of the text as well as the font properties, which in this case are Times New Roman, bold and italicize to name a few, should be maintained from one version to the next. However, if the localized button reads as xe2x80x9cSALIDAxe2x80x9d, the intentional emphasis placed on the original text is lost. This can cause problems in applications where varying font sizes, typeface, and styles are required to effectively convey information to a user of the application. Unfortunately, there is no convenient way for the font properties of text strings to be captured during the localization process, such as from the resource file. This is because the font properties (which are attributes of a text primitive) are generally stored within a temporary data structure allocated for the string known as a device context. The information maintained within this data structure, including the font properties, is discarded by the application from memory after the text is drawn to the screen. Again, this information can only be determined during the actual runtime of the application.
To overcome the limitations discussed above, a way is needed to easily access the graphics primitives and associated attributes of any display object (standard and non-standard) called during the execution of an application. Likewise, a convenient means of determining the context of the text strings that get displayed to a user during the execution of the application is necessary to ensure that the text strings are associated with the correct display object. A way to capture the font properties of a text string or character is also needed so that this information is made available with the other attributes of a graphics primitive.
The present invention provides a mechanism for capturing the one or more graphics primitives associated with an application as it is in execution. Moreover, the invention allows for the detection and retrieval of the unique attributes of the one or more graphics primitives as they are drawn to a graphical user interface. These graphic capturing techniques can be applied directly to any controls, buttons, windows and/or any other display objects that can be invoked by an application, including those that are custom drawn or non-standard with respect to the operating system.
A calling process, such as a localization tool, utilizes the invention to capture graphics primitives, such as text strings, that are displayed to the screen by a target process during runtime. The target process is any computer implemented process or software application that requires a graphical user interface (GUI) to display visual information to a computer user. In operation, the calling process invokes an injection DLL (Dynamic Link Library) to inject a spy DLL into the executable code of the target process. Once the spy DLL is injected, it installs patches and hook functions into the operating system API""s (Application Programming Interfaces) that have routines for displaying text to a graphical user interface. The hook functions monitor the operating system messages generated during the execution of the target application, while the patches allow for the capture of the various graphics primitives and associated attributes of the primitives that are drawn to the user interface.
Whenever a display object is rendered to the GUI by the target application as a result of an invoked action (e.g. mouse-clicking, function key), the hook functions are called to capture the operating system messages passed and the patches capture the graphics primitives of the object. The patches also capture the unique attributes of the graphics primitives, including the font properties of a displayed text. This captured information is then packaged and delivered to the calling process for processing. Because the graphics primitives are captured in connection with the operating system messages passed during runtime, the calling process obtains complete information about any viewable or executable objects displayed by the target process. The operating system messages provide a context for a captured graphics primitive, which allows the calling process to better associate a captured primitive with a specific display object. As an example, a text string primitive can be easily associated with a specific dialogue box that is called by the application as a result of a user action. Furthermore, the invention allows the graphics primitives and associated attributes of custom/user drawn objects to be captured. This overcomes the limitations imposed by the operating system on allowing the unique attributes of non-standard objects to be exposed by the resource file for the application.
Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments that proceeds with reference to the accompanying figures.